With the increased availability of a variety of computing devices that access the internet, many new applications have been developed that leverage internet connectivity and remote provider networks. Computing devices may be stand-alone systems or may be embedded in a variety of products, such as home appliances, manufacturing devices, printers, automobiles, thermostats, smart traffic lights, etc. Many client devices make use of a long-lived connection with a server in order to stream data from the client device to the server and from the server to the client device whenever data needs to be transmitted.
Applications may use various communication protocols, including custom protocols, to implement long-lived connections to multiple client computing devices. For example, a device management application may allow a client to manage thousands of client devices. In many cases, an application provider may need to run a large fleet of servers to listen to the communication protocols and to manage identities and credentials in order to accept connection requests for numerous client devices. Thus, a complicated and costly computer infrastructure may be required in order for an application provider to listen for incoming traffic and to maintain a large number of secure connections for clients.
In some cases, a computing device may communicate with another computing device to provide a stream of data to the other computing device or to send messages back and forth. For example, an audio-visual feed from a security camera may be sent to a remote storage location to store the videos for later use. In order to set up the camera to transmit audio-visual data to a remote storage device, an intermediary infrastructure is required to provide a communication path to transmit the data. For example, software applications may implement various function calls to route data from one device to another device. The process of configuring and modifying the intermediary infrastructure to route data from one device to another device using the appropriate communication protocols can be a burdensome process, particularly for a client that implements a large number of devices.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.